Thorsten Froehlich <tho### [at] trfde> wrote:
>>   (Note that it's not obsolete completely; it has one important role which
>> is a bit different than this. I can explain if someone really wants... :) )

> I think most people here know... ;-)

  Really? Perhaps you are thinking of something else than me.

  The keyword 'inline' has mostly lost its meaning as an instruction for
the compiler to try to inline the function (the compiler will try to do
it anyways, regardless of the keyword). It's very similar to what happened
to the 'register' keyword, which has become completely obsolete.
  However, 'inline' is not an obsolete keyword. It has an important role
which is related to linking.

  Suppose that you have a function implemented in a header file, for
example like this:

double square(double d) { return d*d; }

  Now you use this header file in several cpp files. This means that this
function will be used in several object files (which are what the linker
uses to create the final binary).

  As long as the compiler is able to inline that function there's no
problem. However, if for some reason the compiler is unable to inline
that function, it will create an actual instance of it in the object file,
which means that you will have the same function implementation in
several object files.
  This will cause a collision in the linking stage: The linker will see
two (or more) instances of the same function and will not know which one
of them to use for generating the function calls.

  One solution to this problem which is sometimes seen in actual code
is to declare the function static:

static double square(double d) { return d*d; }

  This means that each object file using this function (still supposing
that the compiler can't inline it) will have a unique ID for this function.
The function calls of an object file will be directed to the unique instance
of the function in that object file.

  This, however, has several problems. The most obvious one is that the
same function will be linked to the final binary several times, needlessly
increasing its size. However, there's a more important problem with this
'trick', and it happens when the function has for example static variables,
eg. like this:

static int increaseCounter()
{
    static int counter = 0;
    return ++counter;
}

  You might have a function like this which is supposed to keep some
information about the execution of the program or whatever.
  However, what happens if this function is used in several object files?
Oops! Each object file uses a distinct instance of this function, each one
with its own 'counter' variable. The purpose of the whole thing got broken.
  When/if the coder doing this discovers the reason he will probably move
the function from the header file to a single cpp file to avoid the problem,
losing the advantage of possibly having it inlined by the compiler. However,
there's a better solution for this:

  Now, here kicks in the real power of the 'inline' declaration. If instead
of making the function static you make it inline, like this:

inline int increaseCounter()
{
    static int counter = 0;
    return ++counter;
}

it will work exactly as it should, even if the compiler is unable to inline
it for some reason.
  This is because the standard requires that if the same 'inline' function
implementation appears in several object files, the compiler must instruct
the linker to merge them into one when linking the final binary. This way
there will be only one instance of the function in the final binary and
all function calls will call this single instance.

  (Btw, the exact same principle applies to template functions. It could
be said that template functions are implicitly 'inline', whether or not
the keyword has been defined for them.)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message